The two best C compilers I use are Power C from Spinnaker and Hi-tech C. I do a lot of programming in C and I find both the Power C and Hi-tech C to work nicely. However; when porting over source code from the MeSsy-DOS platform, Hi-tech C works a lot much nicer because less code has to be modified to be able to execute the program on the C128. Hi-Tech C is public domain last I heard so you can legally get the full version from numerous bbses that carry CP/M files. It runs on a C128 in CP/M mode. Power C is commercial and is available from CMD and Software Support. It comes with 2 disks, one for 128 version and 1 for 64 version. The 64 version has some serious limitations, but the 128 version of Power C doesnt. As for Pascal, I have only used one program and its Boreland's Turbo Pascal, best compiler I ever used. I have Steve Goldsmith to thank for getting me to try it. After seeing his programs that were done in Turbo Pascal and a sample of his code I was very surprised to learn that its the same as the one on the MeSsy-DOS platform. Steve Goldsmith was the one that got me into HI-TECH C and Turbo Pascal. Two very powerful programs/compilers for the 128 Platform ! Turbo Pascal I bought at a flea market and I believe its commercial: I wrote a letter to Boreland Int. a long time ago and never got a response so someone else will have to step in on this one.
Easiest cheapest way to get an 80 column color monitor with your present economic status is to post a message on bbses saying that you have a computer you wish to use and need an IBM CGA monitor and that you are only 13 and have very little $$$. You will be surprised how many sysops and users have CGA monitors in their closets and will often offer them you you for as little as what it costs to ship it to you. CGA monitors are pretty much "useless" on the MeSsy-DOS platform, due to the fact most software requires vga or better to run period.
---------------------------
128 PRG Error
From : RUSSELL PRATER
NATE DANNENBERG writes:
ND> quoting the 128 Programmers reference guide, page 17: "If an array contains fewer than 10 elements, there is no need for a DIM
ND> statement since the C128 automatically dimensions variable names to ten elements."
ND> This would mean then that the array is created as a one dimension array with ten elements numbered from zero to nine.
That's what the book says, alright, but it ain't what happens. It actually DIMs 11 elements, 0 thru 10. If you type in the following:
10 for i = 0 to 20: a(i) = i: next
and run it, you'll get an INVALID SUBSCRIPT error. If you then type print a(10) it will give you the value 10. If you type print a(11) it will give you the INVALID SUBSCRIPT error. So, a(0) thru a(10) exist.
BTW: The C64 PRG has it right. it says "If an array referenced in a program was never DIMensioned, it is automatically dimensioned to 11 elements in each dimension used in the first reference."
ND> (An accomplished BASIC programmer who thinks that using small arrays in this way is wasteful.. If I wanted a five element array, I would make it five elements, rather then letting the computer give it ten...)
I agree. In fact, I just don't believe in using arrays that aren't DIMensioned. If I'm going to use an array, I establish all of my variables in the first couple of lines of the program, then follow that by DIMensioning my arrays.
--------------------------------
Q's: 1. Forth? 2. Screen? 3. ABC80?
From : dbelter@delphi.com
Chris McCormack <chrismc@news-server> writes:
>:1.On a picture in my C64 manual there is a cartrage with a text "Forth" on it. Anyone knows about this? Anyone has it for sale with original manual?
> HES FORTH (from Human Engineered Software) was an old port of FIG-Forth that plugged into the C64 (I think they also had a VIC-20 version). Since FIG-Forth has since been succeeded by Forth-79, Forth-83, and now ANSI-Forth, you may want to find a more updated package. (There was a very snazzy Forth-83 package by Scott Ballantine (sic) called Blazin' Forth which should be floating around the FTP sites.)
There is a program called White Lightning which is also a nice FORTH package, mainly sold in Europe. Just wish I could find the Docs! Also there is one or two FORTH packages for Geos, but I have never tried it. HES Forth, isn't bad but I do agree its alittle outdated.
---------------------
Forth for C-64?
From : brmcf@utkux1.utk.edu
> > MLosh01 wrote:
> I was hoping that you could recommend a good Forth system for the Commodore 64, and point to a source to get it. I have found SFORTH, but have not been able to try it, and know nothing about it.
David Evans wrote:
> There's an in-depth article about how Blazin' Forth works in a Transactor issue somewhere in volume 7, I believe. I'll check.
I'll add that I came across a reference to blazin forth that implied that it is subroutine threaded. If it is, and is F83 compatible, it should be pretty good. The C64 is a good machine for a subroutine threaded forth, because of the efficient call and return in 6502 machine language, the penalty for 16-bit indirect operations used in direct threaded code, and because a JSR only adds a single byte to the FORTH code per word in the definition. There are processors where a subroutine threaded design only gets you about as 2x speed up -- the 68000 for example -- but the improvement in the 6502 inside the C64 is a lot more than that. If it is a single-tasking version that can use the zero-page for an X-indexed operand stack, the speed improvement is even greater.
------------------------
cute basic demos
From : Paul Bryant
how about:
10 J=41848 to 41853
20 read L$:pokej,asc(l$):next
30 dataH,A,C,K,E,R
40 end
what this does is replace the Ready prompt with the word HACKER so instead of the 64 saying Ready it says HACKER, you can stop the program do a Load"$",8 and the ready prompt will be replaced with HACKER or any five letters you substute for the data . The only way out of it is a run stop restore and if you add the line:
5 poke 808,225
or
5 poke 808,234
then run stop restore combination will be disabled. and the only way to get back the ready prompt is to either sys64738 or turn the computer off and back on, or if you have a reset button hit it.
------------------------
Hes Mon 64 Cartridge
From : dan@fch.wimsey.bc.ca
Attached is appendix A of the HESMON 64 manual. Most of the commands will be familiar to m/l hackers, but the E and N commands seem to be unique to HESMON, and bear describing here.
E is used to link a piece of code to a new address in memory by translating addresses in the code. The first two parameters are the starting and ending locations of the code in memory, the next one is the start of the translation table, and the final two parameters give the range of locations to translate. The translation table consists of pairs of addresses--an old address and a new address. The end of the table is denoted by a 0000 0000 address pair. HESMON requests a new address for an old one which is not in the table. This command can be used to translate ROM calls in code from a PET or VIC.
The N command has identical syntax, but instead of the third parameter pointing to a relocation table, it specifies an offset to add to any address in the requested range. A trailing W specifies that instead of relocating code, the scanned range is an address table.
Note also that HESMON uses some memory for its own use. According to the documentation it uses $0120-0141, but I've found it uses the following locations as well: $8000,8235,824D,826A,8270,8279,827F,8D60 (and maybe others).
Appendix A
The HESMON Commands in Brief
The following is a condensed list of HESMON's commands for quick reference. Brackets ([]) denote optional parameters.
A1111 MMM OOOOOO - Simple Assembler
B1111 2222 - Breakpoint Set
C1111 2222 3333 - Compare Memory Block
D1111 [2222] - Disassemble
E1111 2222 3333 4444 5555 [W] - External Relinker
F1111 2222 33 - Fill Memory Block
G[1111] - Go
H1111 2222 33 44 55 ... or
H1111 2222 "XXXXX..." - Hunt for Sequence
I1111 [2222] - Interpret Memory L"name" 11 - Load Program
>Yes, I tried it and it looks awesome!!!! Interlaced mode on the 64 is something I thought was not possible. This is definately the highest resolution Ive seen on the 64.
>infact, the resolution isn't higher than normal hires mode!!! you only can get more colors by mixing them and get more colors
Right.
>into a 8x8 square cause of using multi-color fli + interlace. but you can't increase the resolution over 320x208 (without >sprites) cause the c64 can't move the screen a half pixel.
207 lines and not a single line more!
Of course you can display a full 26th text row, but then one of the previous 25 rows MUST be reduced to 7 raster lines. This is due to the lines on that text-DMA is allowed. Regardless of $d011 it is allowed on the lines $30 (48) to $f7 (247), exact 200 lines. To get as many lines as possible the max. thing is to force text-DMA on line $f7. With switched off borders the full text row will be displayed. As the a text row consists of 8 raster lines and the DMA line is the first raster line it will be displayed from $f7 (247) to $fe (254) (=8 lines).
So the max. visible text screen goes from raster line $30 (48) to $fe (254) which is $cf (207) raster lines over all.
-----------------------
6502? or 6510?
From : John Larkin
Joshua Dickerson writes:
JD> I have a problem... Does the C64 run on 6502 or 6510? i thought the c64 disk drives had a 6510... I ran C64S.EXE (WHICH SUCKS!) and it says the commodor e had a 6510 chip.. confusing to me. i have always been programming in 6502 for the commodore 64 and it worked fine! Also, i forgot about the bug in the JMP operand..
THe 6502 and 6510 were operationally compatible with each other. THe C-64 used a 6510 chip.
JD> if you jumped to a certain adress from a certain address, it got garbled.. anyone who can describe this bug in detail?
According to my book, the bugf only affects INDIRECT jumping, where you would tell the computer to jump to the location contained in a certain address. For example; If you placed the numbers $00, $40 into memory locations $0080 and $0081 and then you did an indirect jump with JMP ($0080) it would jump to location $0400. Location $0080 & $0081 are a pointer to where to jump to.
The bug occurs if you split an idirect pointer at the end of a page. For example; if you placed $00 and $40 in addresses $17FF and $1800 and then did JMP ($17FF) it would screw up and jump to the wrong address. The reason is that when it gets the pointer, it increments the second byte of the pointer address by 1 withouth taking into account that it is a TWO byte address. So it adds 1 to FF, which causes it to roll around to 00. Since the first byte isn't updated, it ends up taking the second part of the address to jump to from location $1700 instead of $1800. (because it sees $17 $FF+1 which = $17 $00)
Just make sure never to split a pointer for an indirect JMP on an address that ends with FF and you'll be fine.
--------------------------
Subj : 6502? or 6510?
From : Nate Dannenberg
To remain on topic, the C64 has a 6510 processor.
The 1541, if I remember right, has a 6502.
In the C128 there is an 8502, as in the 128-D.
THe 128-D also has a 6502 controlling it's internal disk drive.
The 6502/65C02/6510/8502 are all software compatible. To the programmer (that's you) there is no difference from one chip to the next.
About that JMP instruction.... JMP (indirect) on a normal 65xx or 85xx chip has a minor flaw... If you use addresses that do NOT end in FF, say JMP ($0314) (which by the way, that is the JMP command used by the Kernal to cycle thru one of the interrupt routines).... you will never see the bug.
The bug occurs when you do a JMP ($xxFF), such as JMP ($0BFF). Instead of getting the destination address from locations $0BFF and $0C00, it ends up getting the address from $0BFF and $0B00 (it forgets to go to the next page for the high byte!)
Now, if you end up using such a JMP command, it WILL jump, but it will end up using whatever address is in the JMP (indirect) address (low byte) and what is at the first byte of the page (high byte)..
If you put a valid address at the locations that the JMP command would look at under the bug, then the JMP will occur like it should. Say you Say you had the byte $08 at location $0BFF, and the byte $01 at location $0B00. Do a JMP ($0BFF) and the bug will kick in, getting its destination address from $0BFF and $0B00 (which in this case results in $0801)
In C64S, the author corrected that bug so that JMP (INDIRECT) always get's its address from INDIRECT and INDIRECT+1, even if they cross a page boundary.
-------------------------------------
distributed computing
From : alan.jones@qcs.org
Asger Alstrup Neielson proposed using the REU as a large lookup table for multiplying two single bytes to speed up multiplication. Bank 0, address $xxyy is low byte of product of $xx and $yy. Band 1, address $xxyy is high byte of product of $xx and $yy.
And he said that this would work in something like 36 cycles... This is not distributed computing, but it would work and is of interest. Ultimately, I would like to be able to do floating point math faster, as well as 16 bit integer arithmetic and even variable precision arithmetic (say up to 255 bytes). The 6502 family (and the Z80 as well) has no multiply instruction and does multiplication the hard slow way with shifts and adds. I have seen lookup table based multiplication proposed/coded for BCD and ACSII numbers but not for 8 bit binary numbers. This simply uses too much memory. Of course if you have the memory, you might as well use it. As Asger mentioned, it would be faster to get both product bytes from the REU with a single call. I have not coded up any of these ideas or estimated cycle times myself. I do want to offer some further suggestions and cast a wide net for other ideas for doing arithmetic faster on the C64/128.
For fetching one or two bytes of memory using system RAM, even bank switched, would be faster than using the REU. Some timing studies can be found in C-Hacking Magazine. We will never have a full 64K bank of memory available for a multiplication table except in the REU. For the C64 we have banked memory expansion designs available from Bosacki and Pessi. For the C128 we have banked memory expansion designs from Curcio and Pessi. All will provide sufficent additional memory.
Multiplication is commutative: c=a*b=b*a, our lookup table would be symetrical. By say ordering a,b so that a>=b before we access the table will only need about half of it. We do not need to store entries for the case when b=0 since we know c=0 in this case. We could also have special cases for: b=1 c=a, b=2 c=a shifted left with carry. But testing for special cases will slow execution. We could access REU memory in one bank with two accesses. $aabb might return the high byte and $bbaa could return the low byte, with the square $aaaa treated as a special case e.g. store the high bite at $aaaa and the low byte at $00aa. This requires only about 64K of memory instead of 128K. We could also work within two 32K banks, one for each byte of the product. We would need a table of 255 two byte address (or indices) and address the solution like c:=c(t($aa)+$bb). In the case of an REU we would multiply the address by 2 (shift) and fetch the two byte product. For bank switched internal RAM we could fetch the high and low bytes from two separate 32K banks at the same address. No doubt more experienced programmers can figure out the fastest way to code such a table based multiplication scheme using the different memory resources that may be available.
Bruce McFarling suggested using nyble multiplication instead of whole bytes. This would sharply reduce memory requirements and could even be done in say an 8K RAM exapanded CBM disk drive.
Marko sent me MANDELDEMO which says it does 48 bit integer arithmetic within a stock 2K RAM 1541. I don't know exactly what this program does yet, but it does work.
I do most of my number crunching with the standard C64/128 real variables, 4 byte mantissas. I use COMAL with a ML BLAS package. Most of the work is done with SAXPY, SCAL, SDOT, and few divides and trancendental functions. Writing new BLAS routines with faster multiplication would instantly accelerate all of my application programs.
The way do arithmetic fast is with hardware. FLASH 8 may be the way to go but it is expensive, and not yet compatible with NTSC and C128. I would prefer to stick with free (software) or cheap ( <$20 hardware hack) solutions. I once asked a programmer knowlegable about IBM FPUs and FP math routines about the merits of interfacing an FPU (e.g. an 8087) to a C64. He said it could be done but too much time would be lost converting between different number formats. I was not entirely convinced, but I never persued it. Someone recently said that custom ICs, including variants of the 6502, can be done in lots of 10,000 units. I think custom ICs can be done in lots of 1000, but that is still not practical for us C64/128 hackers. There is technology that could monitor the CPU, intercept unimplemented op codes and redirect execution to some other hardware. It is also becoming more common to have fast (RISC?) micro controlers such as the PIC series emulate other ICs. The slow C64/128 is an ideal hacker platform and you don't need to have your own chip factory.
Multiplication is a very simple analytical function. It seems strange to waste so much RAM on it. Still it is a huge consumer of CPU cycles in numerical work and sacrificing available RAM for speed is worthwhile. In terms of distributed computing with a C64/128 using the inteligent drive resources, I thought the drive could be used for evaluating very expensive analytical functions, and functions based on user data. Things like complete eliptic integrals, Bessel functions, etc. could be precomputed and stored on a diskette and the computer could retrieve the function value from the drive. The drive would look up the data from the disk and perform any interpolation and send the result back to the computer. You might have an aircraft simulation running on the computer and nonlinear aerodynamic data, Cm, Cn, Cd, ... tabulated as a function of Mach number, Reynolds number, angle of attack, flap setting... Just send the parameters to the drive and the drive returns the interpolated aerodynamic data needed by the simulation.
